In order to improve software project practice, a number of software process models have been suggested in literature and tested in practice. According to ISO 15504 (ISO/IEC. ISO/IEC 15504-9 Technology Software Process Assessment Part 9: Vocabulary, 1998) a software process is “the process or a set of processes used by an organisation or project to plan, manage, execute, monitor, control and improve its software related activities”. Some of the best known software process models are the waterfall-model (W. W. Royce, “Managing the Development of Large Software Systems: Concepts and Techniques”, in ICSE, pages 328-339, 1987), the spiral-model (B. Boehm, “A spiral model of Software development and enhancement”, SIGSOFT, 11 (4):14-24, 1986) or agile approaches like Scrum (K. Schwaber, “Scrum Development Process”, in OOPSLA'95 Workshop on Business Object Design and Implementation, 1995).
In early software process approaches it was thought that a perfect process can be developed which fits all software developing organisations and all types of projects, but every project has individual needs which have to be accommodated. Therefore, the description of a general solution (i.e. the software process model) has to be adapted in order to be applicable to individual problems. Early approaches to tackle this issue can be found by B. Boehm or by L. C. Alexander and A. M. Davis.
B. Boehm (B. Boehm and F. Belz, “Experiences With The Spiral Model As A Process Model Generator”, in Proceedings of the 5th International Software Process Workshop ‘Experience with Software Process Models’, pages 43-45, 1990) used the Spiral Model to develop project specific software processes. In 1991, Alexander and Davis (L. C. Alexander and A. M. Davis, “Criteria for Selecting Software Process Models”, in Proceedings of the Fifteenth Annual International Computer Software and Applications Conference, pages 521-528, 1991) described 20 criteria upon which the best suited process model for a project can be selected.
Since then many different adaptation approaches have been proposed, but none has become a de facto standard in practice. For instance, Bowers et al. (J. Bowers, J. May, E. Melander, and M. Baarman, “Tailoring XP for Large System Mission Critical Software Development”, in D. Wells and L. Williams, editors, Extreme Programming and Agile Methods—XP/Agile Universe 2002, Second XP Universe Conference Chicago, volume 2418 of LNCS, pages 100-111, 2002) describe the adaptation of the agile software process XP to a project.
Jaufman and Muench (O. Jaufman and J. Muench, “Acquisition of a Project-Specific Process”, in PROFES, pages 328-342, 2005) propose the Emergent Process Acquisition method which creates a project specific process by choosing the most suitable model from a database and by adapting it further. The latter is done by adapting the Meta model of the process by adding and deleting attributes. Afterwards the remaining attributes of the process are instantiated. Thereby the focus is on milestones and on activities and artifacts which have to be executed and created for the milestone. This approach is only cumbersomely applicable to software processes.
The instantiation approach of Yoon et al. (II-Chul Yoon, Sang-Yoon Min, and Doo-Hwan Bae, “Tailoring and Verifying Software Process”, in APSEC, pages 202-209, 2001) uses processes depicted as Activity-Artifact-Graphs. Activities have a name, type, input and output artifacts and are consequently connected by artifacts. Semi automated addition and deletion of activities and artifacts is possible as well as a split and merge of activities. Furthermore syntax checks are available helping process designers maintain consistency when adapting a process. The concept was implemented by using a Process-Management-Tool working on the basis of Petri-Nets. The approach developed by Yoon et al. cannot be directly used for the instantiation of complex processes, because the structure of the process used by Yoon is much simpler.
The prior art approaches for instantiating or tailoring general processes to project specific needs adhere to inherent disadvantages in respect of insufficient visualization and tool support. This leads to imperfect efficiency, because manual adaptation is often necessary which is time consuming and expensive.